Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.93-07-29 < prev next >

Wrap

Text File | 1993-10-16 | 13.2 KB | 318 lines

Internet Engineering Steering Group (IESG) Report from the IESG Teleconference 29 July 1993 Recorded by: John Stewart, IESG Secretary This report contains IESG meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat, which is supported by the National Science Foundation under Grant No. NCR 8820945. For more information please contact the IESG Secretary. iesg-secretary@cnri.reston.va.us. ATTENDEES --------- Bradner, Scott / Harvard Chapin, Lyman / BBN Coya, Steve / CNRI Crocker, Dave / SGI Crocker, Steve / TIS Hinden, Robert / SUN Huizer, Erik / SURFnet Klensin, John / UNU Knowles, Stev / FTP Software Mankin, Allison / NRL Piscitello, Dave/ Bellcore Reynolds, Joyce / ISI Rose, Marshall / DBC Stewart, John / CNRI IAB Liaison Christian Huitema / INRIA Yakov Rekhter / IBM Regrets Gross, Philip / ANS 1. Administrivia o Roll call o Bash the agenda The first hour is to be spent on the Protocol Actions, Working Group Informational Documents, RFC Editor Actions, and Waiting for Area Director Action sections, and the next hour is to be spent on the Management Issues section. o Approval of the minutes The minutes from 24 June 1993 were approved. 2. Protocol Actions o The IESG approved the Internet-Draft "X.400 use of extended character sets" <draft-ietf-x400ops-charactersets-03.txt> for the status of Proposed Standard. ACTION (Stewart): Make the Protocol Action announcement after the Last Call expires. o The IESG approved the Internet-Draft "Compressing IPX Headers Over WAN Media (CIPX)" <draft-ietf-pppext-cipx-04.txt> for the status of Proposed Standard. This action will not be announced until after Dave Piscitello finds out if this document and the IPX Control Protocol document should be advanced together. o Due to comments received during the Last Call, the IESG decided to hold "The Finger User Information Protocol" <rfc1288> at Draft Standard until a new document is submitted for review. 3. Working Group Informational Documents o "Assignment of System Identifiers for TUBA/CLNP Hosts" <draft-ietf-tuba-sysids-01.txt> as Informational Dave Piscitello described this document, and he pointed out that it could be useful to more than just the Internet Community (e.g., the ATM Forum). Allison Mankin said that she would like to review the document before the IESG sent it to the RFC Editor for publication. ACTION (Mankin): Read the Internet-Draft and send comments to the IESG mailing list. o "Assertion of C=US; A=IMX" as Informational John Klensin discussed this with several people while in Amsterdam. He reported that the document does the right thing, but that publishing it as an Informational RFC in the Internet community is the wrong way to do it. Standards like this fall into ANSI's purview, so that is where this should be registered. He said that he expects a new Internet-Draft to be submitted for IESG review. It as suggested that maybe the new Internet-Draft could be published as an Experimental RFC. o "Guidelines for OSPF / Frame Relay" as Informational Some IESGers were concerned about the use of the word "guidelines" in the title of an Informational document. For clarification, it was pointed out that this document discusses IP-OSPF, not the OSPF that runs within Frame Relay clouds. Bob Hinden will contact John Moy. ACTION (Hinden): Contact John Moy. o "Op Reqs for X.400 Mngmnt Domains in GO-MHS" as Informational Erik Huizer reviewed this document and discussed it in Amsterdam. He says that there are two problems with the document: (1) minor editorial problems, and (2) this should be published as Experimental, not as Informational. This item will not appear on future IESG teleconference agendas until the "Surname=Postmaster" document is submitted to the IESG. 5. Management Issues o IESG position on OSI-related work within the IESG A policy was proposed to the IESG for how to deal with OSI- related work within the IETF until the ISO liaison issue is resolved. As of the writing of these minutes, the most recent version of his proposal, including amendments from other IESG members is: Until such time as the relationship between ISOC and ISO has been *completely* resolved, effective immediately, the IESG: - will not charter any new working groups dealing with OSI technology; and, - will not standardize any technology dealing with OSI technology. Existing working groups, new work within the general scope of existing working groups with explicit IESG approval, new work related to IPng, and documents already on the standards track are exempt from this policy. If the relationship between ISOC and ISO has not been *completely* resolved within six months time, this policy will be re-evaluated by the IESG. Since ISOC is working on the liaison, it appeared proper to go ahead with this plan. Although not unanimous, IESG felt that the liaision issue would be less complicated for ISOC if the plan were accepted. There was a debate on the liaison issue itself and whether or not it is something that the IETF needs or wants. This debate was to point out that the issue on the table is that the IESG needs to come up with some kind of policy on how to deal with OSI work while the liaison issue is in limbo. The IESG agreed to instate the policy. o IPng decision process Discussion of this issue was deferred to a special one-topic- only teleconference to be held Friday 30 July at 10:30 EDT, but the comments from that teleconference are included below. There was a fundamental debate about whether the first stage of the IPng selection process was a matter for the Internet Area, or if the entire IESG needed to be present at all stages. No consensus was reached. Another suggestion was to form a blue-ribbon panel consisting of the Internet Area Directors and one or two experts from each of the working groups developing IPng candidates; the point of this suggestion was that a decision cannot be made in a vacuum. No consensus was reached. A suggestion made that several people endorsed, independent of a specific decision process, was to have a list of current documents, a document repository, and an IPng mailing list. Different IESG members had different views on how this mailing list would be used. One point made about this mailing list was that it would be very hard to reach consensus. Several people said that specific criteria for viable IPng candidates needs to be documented. A debate followed in which the issue of recusal was revisited. No consensus was reached. o Registration of types, sub-types, and character sets for MIME John Klensin said that currently the IANA can be asked to register just about anything. He feels that we need a better procedure, and suggested something like an informal Last Call. John Klensin said that he would send a proposal for how to deal with the problem to the IESG mailing list. ACTION (Klensin): Send proposed solution to the MIME registration problem to the IESG mailing list. 6. RFC Editor Actions o "Simple Paging Protocol" as Informational Dave Crocker spoke with the author of this document. He said that the author seemed eager to work within the IETF. This item will remain on the agenda for the IESG teleconferences until the author withdraws the submission from the RFC Editor. o "Reverse BOOTP" as Experimental The IESG agreed to use Dave Piscitello's comments on this document as the IESG's response as a whole. ACTION (Stewart): Send Dave Piscitello's comments on the RBOOTP document to the IESG, the author, and the RFC Editor. o "Encoding Header Field for Internet Messages" as Experimental Dave Crocker was concerned about this document because it was not technically competent in that it cannot be implemented from the document alone. He also pointed out that this document is a new version of an old Experimental RFC. It was mentioned that the 822ext working group considered this approach for MIME, but ended up turning it down because it simply wouldn't work in the Internet. Several people said that this document is a good example of an RFC which, if published, should have a note in it from the IESG telling the reader that there is a competing proposal, which accomplishes the same goal, but is on the standards track. (Note that this is a general request for the RFC Editor, not a one-time-only request for this document.) It was added that the IESG should also have the right to scrutinize RFC submissions more closely which are updates of old Experimental RFCs. A few IESG members said that issues like these made them feel that a new document series for non-standards track material should be created. The IAB liaisons, as well as several IESG members, felt that the creation of a new document series should be an IAB decision. ACTION (Stewart): Add an item to the next teleconference agenda to discuss the IESG's thoughts on a new document series. o "Service Advertisement using the DNS" Dave Crocker said that this is being reviewed by the DNS Working Group. He pointed out that this is the second time a proposal has come before the community on how to make a "reserved for local use" field in the DNS into a standard. o "An Experiment in Remote Printing" as Experimental The IESG had no objections to this document being published as an Experimental RFC. ACTION (Stewart): Inform RFC Editor that the IESG has no objections. o "FTP Operation over Big Address Records" <draft-piscitello-ftp-bigports-01.txt> as Experimental It was mentioned that this specification proposes a general purpose solution that can be used over any of the IPng alternatives and has been implemented by at least two of the alternatives (TUBA and TPIX), and was being studied by a third (SIP) and that it is also suitable for operation of FTP over protocols other than TCP. Because several IESG members felt that this RFC Editor Action over-lapped with the IPng Management Issue, this issue was deferred until after the IPng issue was discussed. ACTION (Stewart): Send to the IESG a draft of the IESG Secretary's message to the RFC Editor so that the IESG can be sure it is in agreement about the details for all of the above RFC Editor Actions. Note that this message to the RFC Editor will include the IESG's request to be able to insert text in Information and Experimental RFCs. 7. Waiting for Area Director Action o "Guidelines for OSI NSAP Allocation in the Internet" <rfc1237> to Draft Dave Piscitello is doing research on this for the protocol write-up. He is also waiting for a decision to be made about whether to make editorial changes to the document. o CIDR documents: <draft-fuller-cidr-strategy-02.txt, draft-ietf-iesg-cidr-01.txt, draft-rekhter-ipaddress-guide-08.txt> to Proposed, and <draft-rekhter-cidr-environment-00.txt> to Informational Bob Hinden would like the Operational Requirements Area to look at these documents and provide input for the Last Call and Protocol Action write-ups. Scott Bradner agreed to do this with the ad hoc Directorate. ACTION (Bradner): Have the ad hoc Operational Requirements Area Directorate look at the CIDR documents. o "DNS Resolver MIB" <draft-ietf-dns-resolver-mib-01.txt> to Proposed The Network Management Area Directorate will review this document in its 6 August meeting. ACTION (Rose): Have the Network Management Area Directorate look at the "DNS Resolver MIB". o "DNS Server MIB" <draft-ietf-dns-server-mib-01.txt> to Proposed The Network Management Area Directorate will review this document in its 6 August meeting. ACTION (Rose): Have the Network Management Area Directorate look at the "DNS Server MIB". o "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)" <draft-ietf-pppext-ipxcp-04.txt> to Proposed Dave Piscitello is researching this to find out if it should progress with the other IPX documents. o Status of "Interactive Mail Access Protocol - Version 2" <rfc1176> Klensin said that a new document is in the works, and that a Last Call could happen soon. He said that he and Joyce Reynolds are looking into this document, along with IMAP3 <rfc1203>, to see which document(s) should move to what status. Dave Crocker asked a general question about Prototype status and if the IESG had ever given a document such a status; if not, he feels that the IESG needs to discuss exactly what that status means. This issue will be discussed on the mailing list. ACTION (D. Crocker): Start a discussion on the IESG mailing list about the exact meaning of Prototype status.